FunnelFlux Pro에는 퍼널을 만들고 완전한 기능을 갖춘 캠페인을 실행하기 위해 필요한 여러 가지 리소스가 있습니다.
그것들은 다음과 같습니다:
- 트래픽 소스
- 오퍼 소스
- 오퍼
- 랜딩 페이지
- 사용자 정의 도메인 (실제로는 리소스는 아니지만 필요함)
아래는 이러한 항목들의 구성과 추적 프로세스에 미치는 영향에 대한 설명입니다.
트래픽 소스
트래픽 소스는 유입되는 방문자의 출처를 정의하며 캠페인 URL을 생성할 때 선택해야 합니다.
트래픽 소스 구성에는 두 가지 주요 구성 요소가 있습니다:
- URL 추적 필드
- 전환 추적
URL 추적 필드 구성
아래 이미지를 참조하세요:
FunnelFlux는 20개의 사용자 정의 추적 필드를 허용하며, 각 필드는 이름(별칭)과 선택적 플레이스홀더 값을 가져야 합니다. 왼쪽의 숫자는 데이터베이스의 열 번호를 나타냅니다. 따라서 이 구성은 이름 -> 열 ID에 대한 매핑을 위한 별칭을 생성합니다.
추적 필드 구성은 리디렉션/직접 링크를 생성할 때 사용됩니다 -- 이 필드들은 URL에 추가되는 트래픽 소스별 쿼리 문자열 데이터를 결정합니다.
제거할 수 없지만 별칭을 지정할 수 있는 두 개의 예약 필드가 있습니다 -- 캠페인 및 외부입니다.
이들은 각각 캠페인 ID 값(또는 캠페인 이름)과 클릭 추적 ID를 위해 예약되어 있습니다.
플레이스홀더는 모두 트래픽 소스가 구문 분석할 토큰/매크로여야 하며(이는 트래픽 소스에서 사용될 것으로 예상되는 URL에 있기 때문입니다), FunnelFlux 토큰은 랜딩 페이지/오퍼 URL에서 트래픽 소스 데이터를 전달하는 데 사용할 수 있는 토큰 형식입니다.
유용한 참고 사항
- 트래픽 소스는 광고 플랫폼일 필요가 없습니다 -- 토큰으로 이메일 병합 태그를 사용하여 이메일용 트래픽 소스를 만들 수 있습니다. 또한 수동으로 생성된 필드를 사용하여 특정 제휴사를 위한 트래픽 소스를 만들고 사용자가 정적 데이터를 전달하도록 할 수 있습니다. 이렇게 할 때는 링크 사용 시 인적 오류를 줄이기 위해 플레이스홀더를 REPLACE로 설정하는 것이 가장 좋습니다.
- 추적 필드의 플레이스홀더가 비어 있으면 생성된 URL에서 해당 필드를 생략하지만 URL 데이터가 존재하면 필드는 여전히 캡처됩니다.
- 캠페인이나 클릭 ID가 URL에 자동으로 추가되는 경우 -- 예를 들어 Facebook이 "FBCLID"를 자동으로 추가하는 경우 -- 예약 필드의 잠금을 해제하고 이름을 바꾸는 것이 합리적일 수 있습니다. 우리의 템플릿에서 외부 필드는 FBCLID로 이름이 변경되고 빈 플레이스홀더가 지정됩니다. 따라서 우리 시스템은 생성된 URL에 FBCLID=를 추가하지 않지만, 들어오는 FBCLID 쿼리 문자열 매개변수 값을 캡처하여 외부 클릭 ID로 저장합니다.
- 사용자는 언제든지 필드 이름을 변경할 수 있으며, 이로 인해 특정 시점에 번호가 매겨진 열에 기록되는 데이터가 갑자기 변경될 수 있으므로 설정 후 각 열 번호로 들어오는 데이터를 크게 변경하지 않도록 주의해야 합니다. 대신 해당 번호가 매겨진 행을 보관하고 새 필드를 만들거나 새 트래픽 소스를 사용하는 것이 더 좋습니다.
- 보관된 추적 필드는 보기 및 보고 드롭다운에서 숨겨지지만 여전히 데이터에 나타납니다. 보관된 필드와 동일한 이름으로 새 행을 만들면 중복 필드를 만드는 대신 해당 필드의 보관이 해제됩니다. 보관된 필드는 URL에서 사용되는 경우 여전히 데이터를 캡처하고 저장하기 때문입니다.
- 필드 이름을 변경할 때 이전 이름 값이 저장되어 이전 링크 URL 데이터를 이름이 변경된 값에 매핑합니다.
전환 추적 구성
여기서 사용자는 트래픽 소스에 전환 데이터를 다시 전달하는 방법을 설정할 수 있습니다.
포스트백 URL은 소스에 대한 간단한 GET 요청으로, 필요한 모든 데이터와 사용 가능한 클릭 ID에 대한 우리의 {external} 토큰을 전달합니다.
HTML은 JS 또는 이미지 픽셀을 허용합니다. 이것이 작동하려면 사용자가 우리의 JavaScript 추적으로 전환을 추적해야 하며, 이는 설정된 경우 HTML 코드를 페이지로 피기백할 것입니다.
사용자 정의 시나리오는 우리가 다양한 트래픽 소스를 위해 만든 사용자 정의 통합으로, 일반적으로 API를 포함합니다.
사용자는 설정 세부 사항을 위해 우리의 도움말 문서를 참조해야 합니다. 이러한 기능은 가능한 경우 활용해야 합니다. 훨씬 더 신뢰할 수 있는 추적을 제공하기 때문입니다. 이들은 모두 서버 간 기반이므로 포스트백 URL로 FunnelFlux에 전환이 전달될 때 작동하지만 JS로 전환이 트리거될 때도 작동합니다.
오퍼 소스
이들은 오퍼의 출처를 정의하며, 일반적으로 제휴 네트워크입니다. 물론 사용자는 "내 제품" 또는 웹사이트 이름과 같은 소스를 만들 수도 있습니다.
이들은 세 가지 목적을 수행합니다:
- 데이터 전달 템플릿화, 오퍼가 이 소스를 사용할 때 데이터 전달 구성을 상속받습니다
- 포스트백 URL 템플릿화, 사용자가 네트워크에 URL을 쉽게 복사/붙여넣기 할 수 있도록 합니다
- 보고를 위한 일반적인 카테고리로 사용
참고: 우리는 가까운 미래에 데이터 전달 패러다임을 업데이트할 계획입니다. 현재 오퍼 소스 구성은 오퍼 구성에서 선택된 시점에 일방향으로 상속됩니다. 사용자가 오퍼 소스를 업데이트해도 오퍼에는 변경 사항이 적용되지 않습니다. 향후에는 오퍼가 먼저 소스에서 데이터 전달 구성(및 일부 다른 구성)을 상속받은 다음 오퍼 수준에서 추가 필드를 설정하고 재정의할 수 있는 엄격한 상속을 만들 계획입니다.
데이터 전달
여기서 사용자는 양식 기반 접근 방식을 사용하여 일반 설정에서 기본 페이지 URL에 추가되는 쿼리 문자열을 만들 수 있습니다.
이 접근 방식은 인적 오류를 줄이고 데이터 전달을 더 잘 템플릿화할 수 있게 해줍니다.
가장 좋은 방법은 기본 페이지 URL에 절대 변경되지 않는 모든 정적 URL 데이터를 포함하는 것입니다. 제휴 URL의 경우, 이는 종종 일부 제휴/오퍼 ID를 포함하는 것을 의미합니다.
이상적으로는 모든 동적 데이터를 데이터 전달 섹션을 통해 구성해야 합니다.
유용한 참고 사항
- vid, n, c, ts 등과 같은 일부 필드 이름은 FunnelFlux 또는 우리의 Javascript에 의해 전달되는 예약된 매개변수에 사용되므로 제한됩니다
- URL 데이터를 전달하려면 해당 옵션을 선택한 다음 쿼리 문자열 키 이름만 입력하면 됩니다. 저장 시 항목은
{data-url_key_name}으로 축소됩니다 -- 우리는 나중에 이를 개선할 계획입니다. - 추적 링크에서 전달된 데이터는 이 토큰을 통해 액세스되며, 우리의 URL 버퍼로 전달된 쿼리 문자열 데이터도 마찬가지입니다. 즉, 정의된 추적 필드가 아닌 리디렉션 또는 액션 링크로 전달된 모든 URL 쿼리 문자열 데이터는 여전히 세션 데이터에 저장되며
{data-url_key_name}으로 액세스할 수 있습니다. 그러나 보고에서는 사용할 수 없습니다. - 복합 또는 기타 데이터를 전달하려면 사용자 정의 문자열을 선택하세요. 여기서 평소와 같이 토큰을 사용할 수 있으므로 예를 들어
{funnel-id}-{campaign}-{trafficsource-id}와 같이 할 수 있습니다. URL 문자열과 같은 복잡한 데이터를 전달하는 경우 인코딩할 필요가 없습니다. 우리 시스템이 저장 시 자동으로 URL 인코딩합니다.
전환 추적
이 섹션은 꽤 자명합니다.
포스트백 URL을 템플릿화하려면 오퍼 소스의 플랫폼이 구문 분석하고 대체할 수익/선택적 거래 ID 토큰을 입력하세요.
히트 ID의 경우 데이터 전달에서 우리의 {hit} 값을 전달하는 필드를 확인하세요. 예를 들어 "aff_sub5"인 경우, 전환 추적 페이지에서 저장된 aff_sub5 값을 나타내는 오퍼 소스의 해당 토큰을 입력해야 합니다. 예: {aff_sub5}
유용한 참고 사항
- 동일한 히트 ID 및 TxID 값으로 FunnelFlux에 전달된 전환은 현재 기존 전환을 대체하지만 중복을 유발하지 않습니다. 현재 이는 전환 타임스탬프를 업데이트합니다. 우리는 이 기능을 원래 타임스탬프를 업데이트하지 않도록 교체할 계획이어서 새 이벤트가 중복인 경우 실질적으로 무시됩니다.
- 현재 전환 추적은 트래픽 소스에 이벤트를 발송하는 것과 관련하여 중복 제거되지 않습니다. 따라서 FunnelFlux가 내부적으로 전환을 중복 제거하더라도 트래픽 소스에 여전히 이벤트가 전송됩니다. 우리는 또한 중복 이벤트를 보내지 않도록 이 동작을 업데이트할 계획입니다.
- 따라서 사용자가 여러 개의 정당한 전환을 발생시키려면 항상 우리의 포스트백 URL/JS에서 "tx" 매개변수를 통해 고유한 거래 ID 값을 지정해야 합니다.
오퍼
오퍼는 중요한 구성을 먼저 상속받기 위해 오퍼 소스를 선택해야 하며, 이는 시간을 절약하고 인적 오류를 줄입니다.
그런 다음 오퍼에는 기본 URL이 있으며, 여기에는 모든 정적 데이터가 포함되어야 하고 모든 동적 데이터는 데이터 전달 섹션을 통해 전달되어야 합니다.
FunnelFlux가 오퍼로 리디렉션할 때, 기본 URL + 데이터 전달 구성 = 최종 오퍼 URL로 리디렉션합니다.
오퍼 카테고리는 순전히 보고에서 그룹화를 위한 것이며 기능적 영향은 없습니다.
페이지 액션 링크
이들은 페이지에서 사용될 액션(CTA) URL입니다. 다음과 같은 일반적인 형식을 가집니다:
https://DOMAIN/action/number
FunnelFlux에서 페이지의 클릭스루 URL(액션 링크)은 목적지를 지정하지 않습니다. 그들은 실행할 "액션"을 참조합니다. 클릭 시 FunnelFlux는 현재 사용자에 대한 퍼널 구성을 처리하고, 현재 알려진 노드 위치를 기반으로 해당 노드에서 액션 X를 실행합니다.
이런 방식으로 FunnelFlux는 사용자의 다음 목적지를 예측하지 않으며, 따라서 클릭스루/액션을 생성하면서 특정 노드로 리디렉션되도록 강제하는 페이지에 링크를 만드는 것은 불가능합니다.
물론 조건 노드를 사용하고 액션 URL로 전달된 일부 URL 데이터를 기반으로 라우팅할 수 있지만, 이는 별개의 기능입니다 -- 랜딩 페이지에서의 액션은 여전히 자연스럽게 다음 예상 노드(이 경우 조건)로 이동합니다.
액션 링크는 일반적이며 페이지, 퍼널 또는 소스에 특정할 필요가 없습니다. 퍼널 빌더 내에서 이러한 액션은 기본 매개변수가 추가된 상태로 검색될 수도 있습니다. 이는 퍼널 기술 문서에서 논의될 것입니다.
통합 제품 ID
이는 베타 단계의 섹션입니다 - 이는 특별히 우리가 구축하려는 웹훅 통합을 위한 것으로, 제품 ID와 방문자 ID를 전달할 것입니다. 오퍼에 제품 ID가 설정되어 있으면 X 제품 ID가 Y 오퍼여야 한다는 것을 교차 참조할 수 있습니다 --> 그것이 전환된 오퍼입니다. 현재는 제한적으로 사용됩니다.
랜딩 페이지
오퍼와 마찬가지로 랜딩 페이지도 단순히 페이지입니다.
아이콘/이름 외에 주요 차이점은 랜딩 페이지에는 구성을 상속받는 "소스"가 없다는 것입니다
랜딩 페이지는 해당 페이지에서의 사용자 행동이나 그로 인한 직접적인 수익을 창출하지 않는 모든 페이지에 사용해야 합니다.
예를 들어, 체크아웃 페이지는 오퍼 페이지일 가능성이 높지만 이전의 제품 판매 페이지는 랜딩 페이지가 될 것입니다. 체크아웃 페이지는 사용자가 최종적으로 전환하는 곳이기 때문입니다.
방문자가 제3자(예: 제휴 네트워크)로 리디렉션되는 종점인 모든 페이지는 반드시 랜딩 페이지가 아니라 오퍼가 될 것입니다.
랜딩 페이지는 전환되지 않지만, 보고에서는 여전히 사용자의 여정 후반에 생성된 수익과 전환을 상속받습니다.